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1.0  INTRODUCTION 


The  Adaptive  Vehicle  Make  (AVM)  program  “META”  projects  have  developed  tools  for 
designing  cyber  physical  (CPS)  (or  Mechatronic)  systems.  Exemplified  by  modem  amphibious 
and  ground  military  vehicles,  these  systems  are  increasingly  complex,  take  much  longer  to 
design  and  build,  and  are  increasingly  costlier.  The  vision  of  the  AVM  program  is  to 
revolutionize  the  design  methodology  of  such  systems  and  reduce  the  design  time  to  one-fifth 
(1/5)  of  the  traditional  systems  engineering  V  methodology  (MIL  -  STD  499). 

The  META  tools  realize  this  vision  by  advancing  a  novel  design  flow  geared  around  the 
following  core  concepts: 

•  Component-Based  Design  enables  design  cycle  compression  by  reuse  of  existing 
technology  and  knowledge,  encapsulated  in  integrated  and  customizable  components  that 
can  be  rapidly  used  in  a  design.  Components  in  CPS  are  heterogeneous,  span  multiple 
domains  (physical  -  thermal,  mechanical,  electrical,  fluid,  and  computational  -  software, 
computing  platforms),  and  require  multiple  models  to  soundly  represent  the  behavior, 
geometry,  and  interfaces,  at  multiple  levels  of  abstractions.  The  META  Language  allows 
creating  multi-model  multi-domain  representation  of  CPS  components  that  are 
composable  by  design. 

Design  Space  Construction  is  supported  by  the  META  Language  using  concepts 
to  represent  design  choices  and  parameterized  components.  These  constructs  in  META 
enable  a  designer  to  systematically  engineer  a  flexible  and  comprehensive  design  space 
for  sub-systems  and  system  that  can  be  explored  for  satisfying  product-specific 
requirements.  The  design  spaces  for  subsystems  and  systems  are  assets  that  encapsulate 
design  knowledge,  which  can  be  reused  in  a  context  different  for  which  it  was  originally 
created. 

•  Multi-Scale  Design  Space  Exploration  incorporates  multiple  methods  that  trade  accuracy 
with  computation  time  for  exploring  the  large  design  spaces.  A  combinatorial  design 
space  exploration  tool  (DESERT),  rapidly  prunes  design  space  using  highly  scalable 
constraint  satisfaction  methods  over  static  properties  of  components  and  designs  (i.e., 
weight,  power,  cost,  etc.).  Higher  fidelity,  higher  computation  time  methods  such  as 
qualitative  reasoning,  ODE  simulations,  are  used  to  further  explore  and  reduce  the  design 
space,  iteratively  converging  over  to  solutions  of  interest,  given  a  set  of  requirements. 

•  Test-benches  for  Design  Evaluation  capture  requirements  in  a  form  that  can  be 
automatically  evaluated  for  a  system-under-test,  using  a  large  set  of  domain-specific 
analyses  -  ranging  from  hybrid  dynamics  simulation,  software  platform  timing 
simulation,  geometric  parameter  evaluation,  finite  element  analysis,  probabilistic 
certificate  of  correctness,  qualitative  simulation,  among  others.  The  model  composition 
tools  included  in  META  operate  over  defined  test-benches  and  synthesize  artifacts 
necessary  for  executing  analysis  in  domain  tools  such  as  Dymola,  Pro-e/Creo,  Truetime, 
Qualitative  Envisionment,  Abaqus,  etc. 

The  META  design  flow  and  tools  are  built  around  the  META  Language,  labeled  the  Cyber 
Physical  Modeling  Language  (CyPhy).  CyPhy  is  a  model  integration  language  which  integrates 
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models  from  different  domains  in  a  semantically  sound  manner  that  enables  reasoning  for 
correctness  of  models  and  modeling  languages.  This  report  describes  the  development  of  the 
CyPhy  and  related  specifications  and  tools  under  the  META  Language  contract  (FA8650-10-C- 
7075). 
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2.0  PROJECT  OVERVIEW 


The  charter  of  project,  as  envisioned  in  the  proposal,  was  to  develop  a  multi-modeling  language 
suite  for  design  and  synthesis  of  Cyber  Physical  Systems. 

2.1  META  Language  Enabled  META  Design  Flow 

The  META  design  flow  (separate  contracted  effort)  articulates  a  design  methodology  and  the 
associated  tool  flow  for  the  CPS  system  design.  The  figure  below  summarizes  the  key  elements 
of  the  META  design  flow,  and  motivates  the  key  functionality  that  was  needed  in  META 
language  to  enable  the  design  flow. 
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Figure  1:  Meta  Language  Suite 
The  META  design  flow  involves  three  core  groups  of  activities: 

1 .  Initial  Architecture  design  involves  modeling  and  rapid  Exploration  of  early  design  space 
sketched  out  with  the  system  requirements.  These  activities  in  design  flow  require  that 
the  META  language  includes  concepts  for  modeling  system  design  space  and  constraints, 
enable  representing  the  key  architectural  variants  that  can  broadly  support  the  customer 
requirements.  The  early  architecture  exploration  also  requires  low  compute  intensity 
methods  that  can  allow  examination  of  lots  of  design  options.  The  META  language  needs 
to  support  modeling  low-resolution  components  to  enable  coarse  grain  exploration. 

2.  The  Integrated  Multi-Physics  and  Cyber  Design  stage  expands  upon  the  broadly 
identified  architecture,  and  refines  them  with  integrated  design  of  physical  and  cyber 
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components  and  conducts  relevant  tradeoffs.  These  activities  in  addition  to  modeling  of 
the  design  space  and  constraints  require  dynamics  modeling  for  progressively  refined 
performance  simulation  of  the  system.  This  phase  also  requires  support  for  computational 
modeling  to  analyze  the  behavior  and  interaction  of  software  with  physical  components. 
Geometry  and  geometry-driven  analyses  are  central  to  the  Physical  nature  of  CPS,  and 
consequently  the  modeling  language  suite  needs  to  support  CAD  and  derivative  analysis 
such  as  thermal,  FEA,  and  allow  evaluation  of  designs  for  manufacturability. 

3.  The  Detailed  Design  stage  involves  further  refinement,  and  analysis,  of  designs  leading 
towards  production,  which  shifts  the  emphasis  of  modeling  capabilities  from  design  space 
to  domain  model  elaboration. 

2.2  META  Language  Multi-Model  Multi-Domain  Components 

In  addition  to  the  diversity  of  the  design  and  modeling  activities,  the  META  Language  Suite 
needs  to  facilitate  representation  of  a  diverse  range  of  cyber  physical  components. 
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Figure  2:  Cyber/Physical  Components 

The  components  that  constitute  a  typical  cyber  physical  system  such  as  a  military  ground  vehicle 
span  a  broad  range  from  commodity  physical  components  such  as  nuts  and  bolts,  to  large 
complex  dynamical  components  like  Engines,  Transmissions,  Sensors,  Actuators,  and 
Controllers.  These  components  can  generally  be  categorized  as: 

1 .  Physical  -  components  consist  purely  of  electro-hydro-mechanical  elements  with  little  or 
no  programmability.  Examples  of  such  components  include  transmissions,  differentials, 
gears,  clutches,  starter-generators,  servos,  among  others.  These  can  be  further 
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categorized  as:  functional  -  implementing  a  function  in  the  design,  or  interconnect  -  that 
act  as  facilitator  for  physical  energy  flow  or  provide  linkages  such  as  nuts,  bolts,  pipes, 
and  tubes. 

2.  Cyber  -  components  are  software  components  that  require  a  computer  processor  to  run, 

and  implement  some  function  such  as  the  Vehicle  Management  Software,  or  controller 
algorithms  implemented  in  software 

3.  Cyber-Physical  -  components  cross-cut  cyber  and  physical  domains,  such  that  they  are 

physical  and  implement  some  function,  however,  contain  deeply  embedded  computing 
and  communication  functions  that  enable  configuration  and  control  of  the  designed 
function.  Modem  combustion  engines  are  a  good  example  of  cyber-physical 
components,  in  that  they  include  programmable  controllers  that  will  interface  with  rest 
of  the  vehicle  management  system  over  communication  buses  (such  as  Controller  Area 
Network  (CAN)  and  TT/FlexRay),  and  allow  optimizing  torque  delivery  by  controlling 
air/fuel  mixture  and  valve  timing  for  optimal  combustion. 

Figure  2  depicts  the  fact  that  META  components  span  across  different  energy  and  physics 
domains.  A  combustion  engine,  for  example,  turns  chemical  energy  into  rotational  mechanical 
energy  while  a  battery  delivers  electrical  energy  from  stored  chemical  energy,  or  an  integrated 
starter  generator  (ISG)  delivers  mechanical  rotational  energy  from  electrical  energy. 

Moreover,  the  components  depicted  in  figure  require  multiple  models  to  describe  and  analyze 
their  behavior.  A  combustion  engine  has  a  Computer  Aided  Design  (CAD)  model  which 
represents  the  physical  geometry  including  mass  distribution,  center-of-gravity,  a  dynamics 
model  will  describe  the  performance  of  the  engine  as  a  function  of  the  driver  and  torque  demand, 
a  thermal  model  will  describes  heat  generation,  distribution,  and  dissipation  as  a  function  of  the 
driver  and  torque  demand. 

Furthennore,  these  different  models  are  often  developed  in  different  domain  tools  i.e. 
ProE/CREO  or  SolidWorks©  tools  are  used  for  CAD  modeling,  while  Dymola  and  Simulink© 
might  be  used  for  modeling  dynamics.  Often  these  models  constitute  an  asset  base  of  different 
engineering  organizations,  and  have  been  developed  with  significant  time  and  resource 
investment. 

These  motivating  and  constraining  factors  had  a  strong  impact  on  the  design  of  the  META 
Language.  The  META  Language  had  to  be  designed  to  represent  components  that  are 
“Heterogeneous,  Multi-Physics,  and  Multi-Model”,  in  such  a  way  that  it  could  leverage  and 
integrate  existing  model  assets  in  domain  tools. 

2.3  META  Language  a  Model  Integration  Language 

The  consequence  of  these  factors  was  that  we  developed  the  META  Language  that  we  call 
CyPhy  as  a  Model  Integration  Language.  A  Model  Integration  Language  is  a  thin  layer  wrapping 
language  that  wraps  the  domain  models  and  exports  only  the  key  interface  and  parameters  that 
are  relevant  for  integration.  The  wrapping  maintains  the  link  to  the  domain  model  -  to  allow 
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integration  in  the  domain  tool.  The  integration  language  has  a  very  small  set  of  native  modeling 
constructs  by  design.  The  native  construction  includes  concepts  such  as  hierarchical  ported 
modules  and  interconnects,  structured  design  spaces,  and  includes  a  variety  of  meta-model 
composition  operators  which  enables  systematic  integration  across  different  domain  modeling 
languages. 
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Figure  3:  Integration  of  Domains  within  Modeling  Languages 

The  integration  is  done  in  a  manner  that  abstracts  the  key  properties  and  interfaces  from  the 
domain  models  that  are  relevant  for  integration  across  domains.  These  constitute  the  key 
variables,  or  design  parameters  that  must  be  reasoned  about  in  a  multi-domain  context.  For 
example,  when  modeling  system  architecture  the  detailed  and  exact  geometry  may  not  be 
important,  however,  the  key  concepts  of  relevance  are  the  join  interfaces,  surfaces  and  constraint 
with  which  components  must  be  physically  attached  to  each  other.  A  systematic  linkage  of  the 
abstractions  and  modeling  concepts  automatically  enables  the  projection  from  architecture 
models  back  into  the  domain  models. 

The  Domain  Tools  and  Frameworks  depicted  in  the  figure  above  are  rich  engineering 
infrastructures  that  were  developed  with  significant  investment,  and  have  accumulated  a  large 
volume  of  Design  Assets,  Intellectual  Property,  Designer  Expertise.  The  Model  Integration 
Language  approach  enables  reuse  of  these  assets  in  the  form  of  a  META  Component  Library, 
and  when  systems  are  built  using  the  components,  the  Model  Integration  Language  approach 
allows  the  projection  of  the  integrated  models  back  into  to  the  Domain  Tools  and  Frameworks  to 
analyze,  visualize  and  refine  the  design. 
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A  model  integration  language  approach  also  allows  opportunistic  linking  and  adds  new  design 
languages  on  demand  enabling  an  open  language  framework,  that  allows  for  adapt  languages  to 
accommodate  evolving  needs  of  design  flows. 

2.4  META  Language  Compositional  Semantics 

A  major  challenge  in  realizing  a  model  integration  approach,  relates  to  the  heterogeneous 
semantics  of  the  modeling  languages  integrated  together.  The  project  addresses  this  challenge  by 
formally  specifying  the  semantics  of  the  integrated  domain  languages,  as  well  as  formally 
specifying  the  composition  semantics.  The  figure  below  illustrates  the  compositional  semantics 
of  integrated  the  Dynamics  Modeling  Language  with  the  Architecture  Modeling  Language 
(AML). 

Figure  4  depicts  a  subset  of  the  meta-model  (meta-models  are  definition  of  modeling 
languages  using  a  UML  class  diagram  notation)  of  the  AML.  The  figure  also  shows  a  subset  of 
the  Bond  Graph  language,  which  is  a  multi-physics  modeling  language.  The  complete  Bond 
Graph  language  is  pretty  large  and  complex,  however,  for  integration  with  architecture  language 
the  core  concepts  that  are  relevant  for  integration  are  abstracted  out.  The  PhysicalComponent  is  a 
tenn  in  Bond  Graph  notation  referring  to  a  component,  and  PowerPoint  are  the  interface  of 
BondGraph  components.  In  the  integration  language  the  composition  is  accomplished  as  follows: 

a)  A  PowerPortType  is  defined  in  the  AML,  and  is  inherited  from  the  Port  concept  in  the 
AML.  This  allows  for  creation  of  power  ports  in  architecture  component  model,  and 

b)  a  containment  relation  is  established  between  the  AML  Components  and  Bond  Graph 
components,  which  allows  embedding  Bond  Graph  components  in  architecture  components,  and 

c)  The  PowerPort  of  Bond  Graph  is  linked  with  PowerPortType  in  AML 

However,  while  this  enables  drawing  Bond  Graphs  within  Architecture  model,  several 
crucial  question  remains  regarding  the  semantics  and  well-formed  compositions.  In  the  META 
language  project  these  questions  are  addressed  by  use  of  FORMULA,  a  constraint  logic 
programming  environment,  developed  at  Microsoft  Research.  The  FORMULA  tool  allows 
specification  and  reasoning  over  well-formed  domain  composition. 
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CyPhyPort  PowerPort  +  PowerPortType. 

CyPhyPath  ::=(src:  CyPhyPort,  dst:  CyPhyPort). 

CyPhyPath(px,  py)  PowerFlow(_,px,py,_) . 

CyPhyPath(px,  pz)  PowerFlow(_,px,pz,_),  CyPhyPath(py,  pz). 

BondGraphPath  ::=(src:  PowerPort,  dst:  PowerPort). 
BondGraphPath(px,  py)  PowerPort2Junction(_,px,  jx,_), 

Dunction2PowerPort(_, jx,py,_) . 

BondGraphPath(px,  pz)  PowerPort2Junction(_,px,  jx,_), 

3unction2PowerPort(_, jx,py,_),  BondGraphPath(py,  pz). 

ViolatingPath  :=  cyPhyPath  is  CyPhyPath(srcPort,  dstPort),  fail 
BondGraphPath(srcPort,  dstPort). 


Figure  4:  A  Meta-Model 
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3.0  RESULTS 


The  outcome  of  this  research  was  the  integration  of  some  modeling  as  well  as  the  development 
of  META  modeling  suite  of  software. 


3.1  META  Semantic  Backplane 

The  Semantic  Backplane  includes  modeling  languages,  models  and  tools  for  the  semantic 
integration  of  Domain  Specific  Tool  Chain  (DSTC)  configurations.  The  semantic  integration  is 
perfonned  by 


1 .  Metamodeling  -  defining  structural  and  behavioral  semantics  of  domain  specific 
modeling  languages 

2.  Metamodel  Analysis  and  Verification  -  composing  and  relating  DSTC-level  domain 
specific  modeling  languages)  and 

3.  Metagenerators  -  automatically  generating  model  translators  from  formal  specification 
of  relationship  between  modeling  languages. 
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Figure  5:  Semantic  Backplane  Overview 


Tools  and  methods  developed  for  the  Semantic  Backplane  are  not  targeting  the  general 
engineering  users:  these  are  for  a  relatively  small  group  of  specialized  experts  responsible  for  the 
semantic  integrity  of  the  evolving  domain  specific  tool  chains. 
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An  essential  element  of  the  Vanderbilt  MIC  tool  suite  is  that  most  of  the  Semantic  Backplane 
tools  are  “metaprogrammable”  and  used  both  in  the  Semantic  Backplane  and  DSTC  levels.  In  the 
followings  we  summarize  the  delivered  components. 

Meta-modeling  provides  the  formal  specification  of  the  semantics  of  the  META  modeling 
language  suite. 

3.1.1  Metamodeling  Languages 

The  meta-modeling  languages  listed  below  are  part  of  the  deliverables.  We  expect  that  the  meta¬ 
modeling  languages  will  continue  to  evolve  beyond  this  project  as  an  overall  consolidation  in  the 
practical  use  cases  for  semantics.  We  are  also  investigating  other  alternatives  such  as  BIP 
(developed  by  Joseph  Sifakis  -  2008  Turing  Award  Laurate)  for  capturing  interaction  semantics 
among  cyber  components. 

The  meta-modeling  languages  are: 

1.  MetaGME++:  the  mature  meta-modeling  language  MetaGME  (a  variant  of  UML  class 
diagrams  and  OCL)  extended  with  generative  constructs.  MetaGME++  is  used  as  meta¬ 
modeling  language  for  all  meta-programmable  tools.  It  has  well  established  relationship 
with  various  standards. 

2.  FORMULA:  constraint  logic  programming  language  developed  by  Microsoft  Research. 
FORMULA  is  used  as  fonnal  language  for  defining  the  structural  semantics  of 
MetaGME ++  and  domain  specific  modeling  languages  defined  using  MetaGME++. 
(MSR  and  Vanderbilt  ISIS  collaborates  in  evolving  FORMULA;  e.g.  current  work 
expands  the  logic  used  in  FORMULA  with  metric  first  order  linear  temporal  logic). 

3.  ASML:  a  language  variant  for  the  Abstract  State  Machine  (ASM)  formal  framework.  We 
use  ASMs  as  common  semantic  domain  for  specifying  discrete  behavioral  semantics  of 
modeling  languages.  ASML  was  selected  because  of  its  availability  in  the  Visual  Studio 
tool  suite.  (We  expect  that  in  the  future  we  migrate  to  FORMULA  as  the  supporting 
theory  evolves).  ASML-based  behavioral  semantics  are  operational  specifications  (as 
opposed  to  denotational)  therefore  they  are  executable  and  suitable  for  generating 
reference  traces. 

4.  DE:  lumped  parameter  differential  equations  as  a  common  denotational  semantic  domain 
for  a  wide  range  of  continuous  time  dynamics.  We  use  a  syntactic  form  that  can  be  easily 
transfonned.  DEs  provide  a  bridge  toward  symbolic  mathematics  tools  developed  for 
order  reduction.  The  provided  semantics  for  continuous  dynamics  is  independent  from 
simulation  algorithms. 

3.1.2  Meta-models 

Meta-models  are  models  of  domain  specific  modeling  languages  describing  the  use  of  meta¬ 
modeling  languages.  Their  goal  is  to  capture  the  formal  structural  and  behavioral  semantics  of 


10 

Approved  for  public  release;  distribution  unlimited. 


modeling  languages.  The  Semantic  Backplane  includes  the  CyPhy  Meta-model  Library  that 
integrates  semantic  aspects  of  a  given  configuration  of  the  META  DSTC. 

Being  a  model  integration  language,  CyPhy  includes  a  core  set  of  language  constructs  for  model 
and  design  space  integration  as  well  as  an  evolving  suite  of  abstracted  languages  imported  from 
various  META  tools.  The  abstracted  sublanguages  are  the  simplest  possible  well-formed  subsets 
of  the  domain  specific  modeling  languages  of  constituent  META  tools  -  still  sufficient  for 
capturing  cross-domain  interactions  (structural  and  behavioral).  Abstracting  sublanguages  for 
multi-model  integration  from  bloated  and  complex  domain  languages  is  an  important  step  toward 
making  META  DSTC-s  practical. 

At  this  point,  the  CyPhy  Metamodel  Library  includes  metamodels  for  the  following 
sublanguages: 

1 .  ADML  (Architecture  Design  Modeling  Language):  represents  hierarchical  component 
architectures  and  typed  interfaces.  Precise  relationship  is  being  defined  between  ADML 
and  component  modeling  sublanguages  of  various  standards  or  frequently  used  modeling 
languages,  such  as  SySML  (in  progress),  AADL  (planned)  and  SL/SF.  This  relationship 
is  defined  as  model  transformation  in  GReAT  (the  MIC  tool  suite  graph  model 
transformation  specification  language)  -  and  in  some  cases  in  FORMULA. 

2.  Architecture  Design  Space  Modeling  Language  (ADSML):  extends  the  design  modeling 
languages  with  constructs  for  design  space  modeling,  allowing  traditional  design 
languages  to  capture  design  spaces  instead  of  just  point  designs.  The  extensions  come  in 
the  form  of  introducing  design  containers  with  model  structure  variability  such  as 
Alternatives,  Optional,  and  variable  cardinality  containment,  as  well  as  Parameterization 
of  design  elements.  Introduction  of  these  design  space  extensions  at  all  levels  within  the 
design  hierarchy  provides  a  powerful  and  compact  mechanism  of  representing  very  large 
design  spaces. 

3.  Bond  Graph  Modeling  Language  (BGML)  (Extended):  is  a  multi-domain  (energy  and 
physical)  formalism  for  representing  lumped  parameter  dynamics  of  physical  systems.  A 
Bond  Graph  represents  energy  flow  across  systems  in  an  energy  domain  neutral  manner. 
Hybrid  Bond  Graphs  are  also  able  to  represent  hybrid  dynamics  with  the  aid  of  switched 
junctions,  and  support  derivation  of  causality  relation  across  systems. 

Beyond  the  core  model  and  design  space  integration  language  elements,  CyPhy  has  been 
complemented  with  the  following  abstracted  sublanguages  imported  from  integrated  tools: 

1.  Simulink/Stateflow  Interface  Language:  The  cyber  aspects,  specifically  the  controller 
design,  are  captured  using  Simulink/Stateflow  models.  The  CyPhy  meta-model  integrates 
an  abstracted  Simulink/Stateflow  meta-model,  capturing  the  input,  output,  and  parametric 
interface  of  Simulink  models  and  defines  associations  with  CyPhy  components  and 
component  interfaces. 

2.  Embedded  Systems  Modeling  Interface  Language  (ESMoL):  The  ESMoL  language 
defines  software  components,  computation  and  communication  platform,  and  allocation 
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of  software  components  on  platfonn.  CyPhy  meta-model  defines  the  relation  of  software 
components  with  CyPhy  components  and  allows  defining  the  sensing,  actuation,  and 
control  path  by  specifying  associations  between  energy  interface  of  physical  components, 
sensors  and  actuators  with  data  interface  of  software  components. 

3.  CAD  Constraint  ML:  represents  geometrical  constraints  (axial  alignment,  surface 
placement,  between  CAD  components  (linked  into  CyPhy  components)  and  allow 
derivation  of  CAD  assemblies  with  a  network  of  geometric  constraints 

4.  Manufacturing  (Cost)  ML:  represents  manufacturing  cost  drivers  for  buy  and  make  parts. 
These  drivers  include  factors  such  as  parts  types,  complexity,  and  counts,  join  types, 
complexity,  and  counts  for  part  assemblies.  The  Manufacturing  ML  is  integrated  within 
CyPhyML  allowing  associating  manufacturing  cost  parameters  with  CyPhy  components. 

5.  Hydraulics  ML  (in  progress) :  is  an  abstraction  of  hydraulics  systems  modeling  primitives 
as  used  for  modeling  Hydraulic  systems  in  COTS  tools  (Boeing  ICCA).  These 
abstractions  are  being  linked  into  the  Fluid  aspect  of  the  CyPhy  component  model. 


The  meta-models  are  represented  in  MetaGME++  and  translated  for  verification  and  validation 
to  FORMULA.  (We  do  not  expect  the  verification  step  fully  completed  by  the  end  of  September. 
Rather,  we  expect  that  the  CyPhy  Meta-model  Library  will  continue  evolving  during  the  tool 
maturation  period  and  beyond  following  the  evolution  of  the  META  tool  chain.) 

3.1.3  Meta-modeling  Tools 

1 .  Generic  Modeling  Environment  (GME):  Vanderbilt’s  meta-programmable  modeling  tool 
is  the  modeling  environment  for  MetaGME++.  Except  the  newly  implemented  support 
for  the  generative  extension  of  MetaGME,  the  tool  is  mature  and  has  been  tested  in  major 
academic  and  industrial  projects.  GME  is  open  source  and  distributed  for  research  as  well 
as  commercial  use. 

2.  Unified  Data  Model  (UDMf.  is  a  meta-programmable  API  tool  that  provides  API-s  to 
programmatically  manipulate  domain-specific  models  built  using  GME  (persisted  in 
GME’s  native  format  or  confonnant  XML).  UDM  is  open  source,  has  multiple 
programming  language  support  (Java,  C++,  .net,  Python),  is  mature  and  tested  in  various 
academic  and  industrial  projects. 

3.  The  Graphical  modeling  environment  (and  associated  toolset)  for  formally  defining/ 
modeling  Model  Transfonnations  as  Graph  Rewriting  specification  over  Domain  Meta 
Models  (GReAT).  The  model  transformations  defined  with  GReAT  can  be  interpretively 
executed  for  rapid  prototyping,  or  compiled  into  executable  specifications  for 
perfonnance.  The  fonnal  definition  provides  opportunities  for  verifying  the 
transformation,  and  allows  for  systematic  evolution  of  the  model  transformation  as  the 
domain  meta-models  evolve. 
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3.2  Cyber  Physical  Modeling  Language  (CyPhy) 

The  CyPhy  Modeling  Language  is  defined  using  Meta-models  (described  earlier).  The  CyPhy 
Meta-model  is  provided  as  a  deliverable  of  this  project.  This  section  documents  the  core 
concepts  of  CyPhy  using  sections  of  CyPhy  meta-models. 

3.2.1  Components 

Components  in  Cyphy  are  the  basic  units  for  composing  system  design.  Components  are  self- 
contained  models  representing  a  physical  or  software  part  of  the  system.  As  an  atomic 
component,  they  are  not  intended  to  be  further  subdivided  at  the  level  of  representation  in 
CyPhy,  but  can  be  used  as  a  standalone  part. 


y  Th«*Jod  Pin 
a flange  a 
? ]  Damping  .constant 
Threaded  Hole 


Damper  diameter  ■ 
flangebQ- 
Damptng  gain  r| 
Damping  offset  ~rj 


Damper_10 


Figure  6:  Example  Component  Model 

The  component  model  represents  several  things  about  the  actual  component,  including  its 
physical  representations  and  connections,  its  dynamic  behavior,  and  numerical  properties.  The 
component  in  figure  1  shows  several  connections  for  structurally  connecting  (Threaded  Pin  & 
Hole),  dynamically  connecting  (flange_a/b),  and  parameters  (Damping  Constant,...).  These 
aspects  are:  physical  implementation,  Dynamic  and  Cyber. 

Physical  implementation:  The  component  will  have  a  3D  shape,  and  various  physical  properties, 
such  as  mass,  center  of  gravity,  3D  geometry  (CAD).  As  the  components  are  interconnected  into 
assemblies,  subsystems  and  systems,  the  interfaces  are  carefully  defined  to  pennit  composition 
of  models.  The  physical  properties  of  the  model  are  shown  in  the  Structural  Aspect  of  the 
model. 


Figure  7:  Physical  -  Inside  the  Structural  Aspect 

Dynamics  are  the  component  behaviors  in  one  or  more  domains  (e.g.,  Electrical,  Thermal, 
Mechanical-Rotational,  Mechanical-Translational,  Hydraulic,  etc.  Dynamics  is  expressed  in  the 
Modelica  language,  which  uses  a  mix  of  Causal  (directional  input  or  output  is  assigned  to  each 
port)  and  Acausal  (power  flows  either  direction  based  on  its  context,  as  in  most  physical 
systems). 


13 

Approved  for  public  release;  distribution  unlimited. 


Cyber  is  the  software  is  a  critical  part  of  the  cyber-physical  system  design,  with  many 
components  having  a  physical,  dynamic,  and  software  implementation.  The  Cyber  aspect 
captures  the  software  representation.  The  Cyber  aspect  is  intended  primarily  for  specifying 
controller  logic  for  the  system.  Controllers  can  be  specified  in  a  combination  of  state  diagrams 
and  signal  flow.  Software  is  automatically  generated  from  these  models. 


Figure  8:  Example  Dynamics  Model 

In  summary,  components  are  multi-domain  and  multi-model,  include  interfaces  for  composition, 
have  properties  for  informational  and  analytical  evaluation,  and  can  be  parameterized. 

3.2.2  Design  Spaces 

Using  components  and  assemblies  allows  the  designer  to  capture  a  single  design  architecture, 
with  a  single  choice  of  components.  This  has  several  drawbacks: 

Requirements  often  change  during  the  design  process,  sometimes  necessitating  a  redesign. 

Component  and  subsystem  behavior  is  discovered  during  the  design  process,  and  the  best  choice 
of  architecture  and  components  may  not  be  apparent  until  late  in  the  design  process. 

The  design  is  applicable  to  a  single  target  use,  and  can  require  substantial  rework  for  other 
applications. 

Instead,  CyPhy/OpenMETA  offers  the  concept  of  a  Design  Space.  The  design  space  allows  the 
models  to  contain  multiple  alternatives  for  components  and  assemblies.  Any  component  or 
assembly  can  be  substituted  for  another  component  or  assembly  with  the  same  interface. 

The  editor  offers  a  simple  syntax  for  capturing  design  options.  A  design  alternative  container  is 
created  with  an  interface  matching  a  component  and  the  component  is  placed  inside  and  wired  to 
the  external  interfaces  (there  is  a  tool  to  automatically  do  this).  Additional  alternative 
components  (or  assemblies)  are  added  to  the  alternative  design  container. 

The  semantics  of  this  construct  are  to  choose  one  of  the  internal  components  in  place  of  the 
alternative  container. 
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The  design  space  is  the  combination  of  all  options  of  all  alternatives.  Consequently,  the  design 
space  can  get  very  large  (i.e.  Design  space  size  is  #  Altl  *  #  Alt2  *  #  Alt3  *...).  While  this  is  a 
powerful  mechanism  to  expand  the  range  of  designs  under  consideration,  a  mechanism  is  needed 
to  limit  the  design  space  to  a  manageable  size.  For  this  purpose,  design  space  constraints  can  be 
specified,  and  used  by  the  Design  Space  Exploration  Tool  (DESERT). 


Figure  9:  Example  Design  Space  Alternative 

Design  space  constraints  are  simple,  static  operations/equations  that  can  be  specified  on  the 
properties  or  identities  of  components  or  assemblies  in  the  design  alternative  space.  Operations 
on  the  properties  such  as  total  weight  and  cost,  thresholds  on  a  component  property  (e.g.  TRL  > 
3),  or  identity  (e.g.,  all  wheel  types  must  match  -  do  not  mix  and  match). 
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Figure  10:  Example  Constraints 

The  DESERT  Tool  uses  scalable  techniques  to  apply  these  constraints  to  very  large  design 
spaces  to  rapidly  prune  the  design  space  to  a  manageable  size.  The  figure  below  shows  the 
design  space  for  the  simple  drivetrain.  Prior  to  applying  constraints,  there  are  288 
configurations.  After,  there  are  48.  Typical  design  spaces  can  easily  reach  10B  configurations. 
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After  proper  constraint  application,  these  can  be  reduced  to  1000s.  Design  space  creation  and 
exploration  is  a  process  of  expansion  and  contraction  of  the  design  space.  It  can  be  a  powerful 
tool  to  build  adaptable,  flexible  designs. 


Desert  Connguraboo  Ootog 


0*0*4  C«"*tgir*WS! 
r  Con<o*aBon 

Cents  No.  IS 
CaAjto.rt 
C^Sst*>.» 
CorS«M>.7t 
Contgt*,.?? 
C.orrfg»*>.2J 

Cor4sM>.7$ 

ContgM>.» 

Cr*e*>.V 

C<r4g>*».!3 

Cw<«sMo.» 

CbA)No.» 

Co^QNo-32 
Cr*gN9.33 
C**gMo.34 
CoMgNo.35 
OOgN»3t 
CoMgNs.37 
Co"8gNo.38 
Co««gN0.39 
CO^OMo.tO 
Cor4gNs.41 
C<y*gN8.42 
CoMgNa.43 
C<y*gNo.4t 
:  CootgNo.HS 
□  CorrtgNo.46 
CorrtgNo.47 
!3  ConSgtij.es 


-  Dns*JlniftJv  [Atorawe] 
i>«e.Sh*»t_o  [itt/saai 
Drv*Jh^t.hi_OrN*  JhilS.I  [1-W2B8] 

'.twjmtju  (UCemMve] 

rn*l J>t,e  J  |K/2Sfl] 

(K/288! 

n(M_*d8  JXrHUtt  [Da*C<tjnf, 

Dr**  J*snj*a  [MtCRBtM] 

»w.V>»ft_0  ['.*V2W] 

y**Jh*ftj*B_Sn*Jh»ft_l  [1*4/288] 

F»m/  Or«r  tin  |ASr<fVit-^; 

rHWJ>m«.0  [M/M] 
ten!  [WnO] 

Corr«tet  [288/2881 
<JM$J)nrtJlrtr*  [MMmftM] 

_OnaJ>urjrira_OotiSn*Jranmrmv'J.  [144/»8! 
Ooi*>N».t>*r»rmn.  0  [;•«/»■] 

It  !  Cngne_»_Cwm»<tor  [Concrxnd] 

Comte  IMfl/jafl] 

-  Lngne  [Alter**.*] 

<3.£nO’«-0 172/288] 

CI_»ngn*_»  (W2«fl 
G_£ngre_2  {72/288] 
fns»w_Cl  JSnjne.3  (7J/288J 

[288/288] 


,  Bften»H«n")  |  O08»*i  ~j 


Figure  1 1:  Design  Space  Exploration.  Before  and  After  Constraint  Application 

3.2.3  Design  Evaluation  (Test  Bench) 

While  application  of  constraints  can  eliminate  design  alternatives  based  on  simple,  static 
properties,  much  of  the  system  behavior  (desirable  and  undesirable)  emerges  from  the  dynamic 
interaction  between  components.  These  interactions  occur  across  and  between  any  and  all  of  the 
physical  domains  within  the  spectrum  of  the  model  coverage. 

Evaluation  of  a  model  configuration  can  be  done  vs.  requirements  imposed  on  a  system  design. 
Requirements  are  expressed  in  terms  of  Metrics  that  can  be  computed  on  the  system  models. 
Metrics  might  include  speed,  maximum  towing  force,  or  acceleration  time.  Requirements  are 
tests  on  these  metrics.  Typically,  the  conditions  and  scenario  will  be  specified  for  a  requirement 
CyPhy  support,  e.g.  Level  ground,  Pavement,  and  the  scenario  of  Driver  Throttle  at  100%.  For 
example,  “the  vehicle  must  accelerate  from  0  to  60  MPH  in  less  than  8  Seconds”. 

System  performance  evaluation  is  specified  via  a  Test  Bench.  A  test  bench  is  an  executable 
specification  of  a  requirement  analysis.  The  parts  of  a  Test  Bench  are: 

•  Test  Drivers,  reproducing  the  stimulus  to  the  system 

•  Wraparound  environment,  providing  the  interfaces  at  the  periphery  of  the  system  (e.g.  the 
ground  interface  with  the  tires,  the  external  air,  ...) 

•  Metrics  evaluation,  taking  measurements  of  the  system  properties  and  converting  into  a 
value  of  interest.  The  metrics  are  also  tied  to  requirements,  which  can  convert  the  metric 
to  a  design  “score”.  And, 
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•  The  system  under  test  -  either  a  point  design  or  a  design  space.  In  the  case  of  a  design 
space,  the  test  bench  can  be  applied  over  the  entire  set  of  feasible  designs. 

The  test  benches  are  tied  to  specific  workflows.  Currently,  CyPhy/OpenMETA  implements  test 
benches  for: 

•  Dynamics,  using  a  lumped  parameter  model  executed  in  the  Modelica  language. 
Dynamics  cover  mechanical,  electrical,  hydraulic,  and  thennal  domains. 

•  Structural,  using  3D  CAD  assemblies  to  evaluate  the  physical  compatibility  of  parts, 
locate  potential  interference,  and  compute  physical  properties  such  as  Center  of  Gravity, 
Bounding  Box,  and  assembled  location  of  specific  points  on  the  system. 

•  Finite  Element,  using  Finite  element  techniques  to  compute  stress/strain,  thermal 
propagation,  computational  fluid  dynamics,  etc. 

•  Mobility,  using  the  NATO  Reference  Mobility  Model  to  predict  vehicle  mobility  based 
on  aggregate  system  properties, 

•  Cyber,  co-simulating  dynamics  with  a  time-based  software/processor/network  simulation. 

•  Manufacturability;  creating  the  3D  CAD  files  containing  the  properties  of  each 
manufactured  join  between  parts,  and  an  electronic  Bill  of  Materials.  From  this  design 
package,  iFAB  can  predict  a  cost  and  schedule  to  manufacture  the  system. 

•  Complexity,  evaluating  the  graph-energy  complexity  of  the  system  based  on  its 
component  complexity  and  structure  of  its  connections.  The  complexity  metric  will 
correlate  with  system  cost  and  schedule. 

Test  bench  also  has  a  set  of  limits  associated  with  part  minimum/maximum  parameters,  (such  as 
maximum  torques  on  a  drive  shaft),  design  limits  associated  with  an  assembly  or  the  use  of  a  part 
in  a  system  (such  as  minimum  allowed  battery  charge).  The  limits  are  automatically  evaluated 
with  each  evaluation  of  a  test  bench.  If  limits  are  exceeded,  a  test  bench  result  can  be  ignored  or 
otherwise  modified  or  treated  with  less  trust. 
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Figure  12:  Example  Test  Bench 
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LIST  OF  ACRONYMS,  ABBREVIATIONS,  AND  SYMBOLS 


ACRONYM 

DESCRIPTION 

AVM 

Adaptive  Vehicle  Make 

AML 

Architecture  Modeling  Language 

CPS 

Cyber-Physical  Systems 

CAN 

Controller  Area  Network 

CAD 

Computer  Added  Design 

ISG 

integrated  starter  generator 

DSTC 

Domain  Specific  Tool  Chain 

DESERT 

Design  Space  Exploration  Tool 

META 

META  is  not  an  Acronym.  This  is  the  program  name  as  presented 
by  DARPA/TTO  AVM 

OCL 

Object  Constraint  Language 

UML 

Unified  Model  Language 
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